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© MEF Forum 2020. All Rights Reserved. 

The information in this publication is freely available for reproduction and use by any recipient 
and is believed to be accurate as of its publication date. Such information is subject to change 
without notice and MEF Forum (MEF) is not responsible for any errors. MEF does not assume 
responsibility to update or correct any information in this publication. No representation or 
warranty, expressed or implied, is made by MEF concerning the completeness, accuracy, or 
applicability of any information contained herein and no liability of any kind shall be assumed by 
MEF as a result of reliance upon such information. 

The information contained herein is intended to be used without modification by the recipient or 
user of this document. MEF is not responsible or liable for any modifications to this document 
made by any other party. 

The receipt or any use of this document or its contents does not in any way create, by implication 
or otherwise: 

a) any express or implied license or right to or under any patent, copyright, trademark or 
trade secret rights held or claimed by any MEF member which are or may be associated 
with the ideas, techniques, concepts or expressions contained herein; nor 

b) any warranty or representation that any MEF members will announce any product(s) 
and/or service(s) related thereto, or if such announcements are made, that such 
announced product(s) and/or service(s) embody any or all of the ideas, technologies, or 
concepts contained herein; nor 

c) any form of relationship between any MEF member and the recipient or user of this 
document. 

Implementation or use of specific MEF standards, specifications, or recommendations will be 
voluntary, and no Member shall be obliged to implement them by virtue of participation in MEF 
Forum. MEF is a non-profit international organization to enable the development and worldwide 
adoption of agile, assured and orchestrated network services. MEF does not, expressly or 
otherwise, endorse or promote any specific products or services. 
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1 Abstract 

This White Paper is aimed at Communications Service Providers (CSPs) and their VNF vendors 
who are currently challenged with introducing large numbers of VNFs into the Service Provider’s 
environment due to high overhead involved in agreeing and managing VNF licenses. Today’s 
non-standardized VNF licensing environment is holding back the rapid introduction of innovative 
new VNF products into the telecom environment and is a barrier to entry for many smaller VNF 
vendors. This problem will become increasingly acute with the growing deployment of SD-WAN 
managed services, 5G and Edge Compute by CSPs. 

This paper explains the current state of lack of adoption of even initial attempts at standards for 
VNF licensing. Proposals are made by the authors to address the lack of scalability of VNF 
licensing and deployment through standardized terminology, constructs and a scalable VNF 
Licensing Management architecture aligned with that of MEF’s LSO (Lifecycle Service 
Orchestration) framework. 


2 Introduction 

Communications Service Providers (CSPs) or ‘Service Providers’ are increasingly using Virtual 
Network Functions (VNFs) to enhance their product offerings - for example SD-WAN managed 
services - as well as to enable deployments of 5G and Edge Compute. 

VNEs are pure software entities that can be deployed in a compute environment anywhere in the 
network and can be cloned and deployed extremely quickly. However, VNE vendors have to 
realize return on their development investments in the technology and therefore need to have 
intellectual property rights associated with them. Just as with any other networking product, 
VNEs therefore have rules and conditions for their use set by the VNE vendor. The intellectual 
property rights (IPR) associated with the VNE may also include IPR for components from third 
parties that have been used in the development of the VNE. Eor these reasons, among others. 
Service Providers using VNEs have to negotiate the use of VNE products with their vendors and 
mechanisms for monitoring adherence to rules and conditions of use have to be agreed and 
implemented. 

Aspects of such rules and conditions for use of VNEs include: 

• Conditions of VNE use: What are the conditions in which a VNE can be used or not used 
by the Service Provider? 

• Duration of VNE use: What is the timeframe for usage by the Service Provider (single 
use, annual, in perpetuity, other)? 

• Changes to VNE: What modification permissions (if any) does the software owners grant 
to the Service Provider user of the VNEs? 

• Business model for VNE use: How will the license users pay the software owners as they 
use a VNE license over the course of business? 
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The term 'license' is typically used as shorthand for these rules and conditions of use of a VNF, 
and we would say that a Service Provider has a license to use the VNF as long as it adheres to 
the rules and conditions set by the VNF vendor. Some Service Providers have not yet fully 
understood the challenges associated with VNF licensing from multiple VNF vendors. VNF 
license negotiation between Service Providers and VNF vendors is very often a cumbersome and 
expensive legal and commercial exercise that can last several months and it can drastically slow 
down the introduction of new VNF products into Service Provider environments acting as a 
major barrier to innovation by large and small VNF vendors alike. Even when the challenge is 
understood in the commercial and business parts of the Service Provider, there is often a 
significant barrier for those groups in the Service Provider to articulate and achieve 
implementations of their requirements from the counterparts in the operational departments of 
the Service Provider. 

Enforcement of the terms of the VNE license is very central to the use of VNEs. The nature of 
software makes it very easy to copy and reuse - and therefore also easy to abuse the terms of the 
software licence. To help counter this possibility, VNE Vendors often use a mechanism in which 
the VNE software itself enforces the terms of the license and also measures the VNF’s usage. 
Enforcement is the responsibility of the VNE Vendor and for that reason, enforcement is 
implemented by the VNE Vendor. This can be done in a proprietary manner and there is no 
intention to standardize the mechanism for enforcement. 

However, enforcement as it is typically implemented today requires the ability either to send 
reports to the VNE Vendor directly over the Internet or to implement very expensive audits. This 
is where there is a need to standardize the tracking and reporting around the usage of the VNE. 
This ties directly into having a more effective trust model between the Service Provider and the 
VNE Vendor and is also central to the need for standardization (see Section 7). 

Also, due to lack of operational standardization of the management of licenses. Service Providers 
often have great difficulty introducing VNE-oriented mechanisms into their existing BSS/OSS 
environments, acting as an additional barrier to the use of VNEs in Service Provider products. 
Examples of causes of lack of progress in this area appear to include the required costly changes 
to the Service Provider’s legacy OSS/BSS in order to accommodate proposed VNE license 
management approaches, concerns about sharing information on the usage of the VNE by the 
Service Provider with the VNE vendor (usage monitoring), as well as architectural requirements 
on the part of both Service Providers and VNE vendors. 

This contrasts starkly with the apparent ease of using VNEs in the hyperscale cloud provider 
environment. There is indeed much that can be learned from the cloud service providers’ 
implementation of “charging and billing” and could be used for the possible standardization of 
VNFaaS (VNE as a service). However operationally there is a fundamental difference between 
the CSP context and that of the cloud provider. In the CSP case of, the vendor provides the VNE 
(VNF instance) but the run time is managed by the CSP. 

The problem is only growing in complexity. A Service Provider will typically have many 
potential sources for VNF products, and each VNF vendor has its own approach to licensing and 
monitoring. Furthermore, Service Providers may be using wholesale network services from 
partners to complete the footprint of a given service for a customer and may need to trigger the 
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use of VNFs not only in its own network, but also in the network of the wholesale partner (e.g. 
service chaining on an offnet uCPE). 

The scale of the challenge of managing VNF licenses for the Service Provider is illustrated in 
Figure 1. A Service Provider can expect to work with tens of VNF vendor partners. Fach VNF 
vendor comes with at least one VNF license manager for its VNF products. Each VNF license 
manager will be handling at least tens of VNF policies and thousands of VNF instances. Multiply 
this out, and each Service Provider could well face the task of managing millions of associations 
between VNF instances and VNF policies. 
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Figure 1: Farge scale of VNF instances and license keys in Service Providers 


Even standardizing terminology around VNF licensing appears to be a challenge, also confusing 
and fragmenting the market to the detriment of market growth and innovation. 

Fooking to the future, the ability to rapidly clone VNFs and deploy them means that automation 
of VNF lifecycle management is absolutely essential. Automation can only occur when 
terminology, constructs, architecture and interfaces for license management have also been 
standardized. 

This White Paper proposes standardized terminology and an architecture aligned with the MEF 
Fifecycle Service Orchestration (FSO) architecture for standardized VNF license management. 
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The goal of standardized license management is to minimize commercial, business and 
operational friction experienced by both CSPs and VNF vendors. 


3 Industry Standardization Background 

Standardization work related to VNF licensing has already taken place in organizations such as 
TM Forum and ETSI. It is instructive to understand at a high level the results of that work in order 
to understand how using MEF standardization paradigms help the service providers and VNF 
vendors eliminate, or at least greatly reduce, the commercial and business friction they currently 
experience. 


ers!^ 
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Figure 2: SDO approaches to VNF Eicense Management 


3.1 TM Forum 

In March 2017, TM Eorum released it Erameworx Exploratory Report on Eicense Management 
[1] covering the challenges and requirements of VNE licensing, as well as the use cases and 
functional architecture and interfaces relating to VNE license management. 

The resulting TM Eorum work highlighted the need for standardized industry taxonomy in this 
area which should be used for communications between business and operations teams, and 
between vendors and suppliers. 

3.1.1 Architecture Proposed in TMF IG1143 

TM Eorum proposed the following architecture to be used for reference, analysis and validation 
of current and future requirements. 
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Figure 3: Proposed TM Forum VNF License Management Architecture 


3.1.2 License Management 

TM Forum also introduced the concept of 'license management' (cf. 'license manager' - see below) 
License Management would be the centralized entity in a service provider domain for management 
of all the VNF licenses in that domain irrespective of VNF type, VNF vendor etc. 
The License Management would comprise the respective License Managers supplied by either the 
VNF vendor, or a 3rd party managing the VNF on behalf of the VNF vendor. 
Externally, the License Management interacts with all instance of MANO, and internally provides 
vendor and technology agnostic APIs for interacting with the individual License Managers. 
Protection of VNF Licenses is not in the purview of License Management system. 

3.1.3 License Manager 

Finally, TM Forum introduced the concept of 'license manager' as an application provided by 
the VNF vendor or a 3rd party for protecting in an implementation specific way against use of 
VNF's outside the scope of the license. 

The License Manager would be a gateway between Service Provider and VNF vendor/3rd party 
and would be separate from the MANO to ensure that the application wouldn't interfere with 
MANO operations. 

All License Managers from the various vendors would be registered in the License Management 
system. 

These TM Forum concepts have not yet been adopted in the industry. 
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3.2 ETSI-IFA 

Since the TM Forum finished its work in this area, ETSI-IFA [2] has been exploring VNF 
licensing issues including 

• License management architectural considerations and architecture 

• Interface requirements for license management 

• Information model requirements for VNF licenses 

• Security requirements for VNF licenses 

Discussions in ETSI-IFA are ongoing, but ETSI’s focus is in the operation and management 
areas relating to VNFs, however VNF Licenses will be managed in the domain of BSS/OSS. In 
addition, license related information will be made by BSS/OSS (VNE License Management 
functional block) to NEV-MANO. 



Eigure 4: Ongoing work in ETSTIEA 


4 Proposed Standardized Constructs and Terminology 

The authors of this paper propose that the work of ETSTNEV and TM Eorum described above 
needs to be enhanced and completed in alignment with MEF’s Lifecycle Service Orchestration 
(LSO) Reference Architecture [3] so that Service Providers will be able to handle VNE licensing 
in an automated and scalable way. In this section, we describe the various pieces in the VNE license 
operational environment, and where required propose new terms and definitions. 

4.1 Virtual Network Function 

The basis for all VNE licensing is the Virtual Network Function or ‘VNF’ itself. The VNF is 
executable software which is a product with its own product lifecycle. It is developed and delivered 
to the market as a product by VNF vendors. The VNF can be used by a range of entities including 
Service Providers. 
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There are a huge number of examples of VNF products including: 

• Edge Devices: SD-WAN Edge, vCPE, IP Edge 

• Switching: BNG, CG-NAT, routers 

• Tunnelling gateway elements: IPSec/SSE VPN gateways 

• Traffic analysis: DPI, QoE measurement 

• Signalling: SBCs, IMS 

• Application-level optimisation: CDNs, load Balancers 

• Home routers and set top boxes 

• Mobile network nodes: HER/HSS, MME, SGSN, GGSN/PDN-GW, RNC 

• Network-wide functions: AAA server’s policy control, charging platforms 

• Security functions: Eirewalls, intrusion detection systems, virus scanners, spam protection 


4.2 VNF Instance 

The VNF Instance or 'VNF-i' is a live copy of the VNF running in a live environment. There can 
be any number of VNF-i's for a given VNF. Each VNF-i must have its own unique identifier which 
is generated by NFV MANO. The VNF-i itself is also instantiated and operated by the NFV 
MANO. However, the related license information is provided and managed by the VNF Eicense 
Manager in turn supplied by the VNF Vendor. Note that when referring to VNF-i’s, it is important 
to distinguish between the VNF product and the instance of a VNF product. 



Figure 5: VNFs and VNF instances 


Example 

A VNF might be a pure software firewall product that can be used at the edges of an SD-WAN 
service on a uCPE. The actual instance of the firewall on a given uCPE at a specific customer 
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site is the VNF-i. If the service using the VNF has say 100 edges, there may be 100 VNF-i's or 
instances of the VNF firewall product. 

It is also important to note that the service provider may have agreed a price with the vendor for 
which the service provider can use up to a total 500 instances of the VNF product in different 
customer deployments at any given moment . The service provider may then activate and 
deactivate VNF-i's rapidly in order to ensure that it gets the maximum use of the 'pool' of 500 
VNF-i's at any given time. The VNF vendor in this case has licensed the service provider to use 
its VNF product (the firewall), but on condition that it uses no more than 500 live copies, or 
VNF-i's. of the VNF product at any given moment. It is important for the VNF vendor, as well as 
the service provider, to know how many VNF-i's are being used at any given moment by the 
service provider. More on this later. 


4.3 VNF License 

A VNF License or 'VNF-li' is a logical entity with a unique identifier which is associated with a 
VNF product. It expresses the agreement of the owner of the VNF product to have it used by one 
or more users. In simple language, the VNF user may say "I have the license to use this VNF from 
the VNF Vendor". The VNF License does not have to include commercial terms. 



Figure 6: VNF and VNF license 
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4.4 VNF License Policy 

A VNF License Policy or 'VNF -Ip' is the set of rules and conditions constraining the use of one 
or more VNF instances. For example, the vendor may want to limit the use of its VNF product to 
a specific country or set of countries, or it may want to limit the number of simultaneous 
instances of its VNF product. Similarly, it may want to limit the duration of use of the VNF and 
often, there is a limit applied to the number of concurrent users of a VNF. 

All of these rules and conditions are captured in a VNF-lp. 

Explicitly, an attribute of VNF-lp is a rule or condition. Examples of VNE-lp attributes include: 

• Number of simultaneous users of VNE-i 

• Eocation of use of VNE-i 

• Modification permission for VNE-i 

• Number of cores running VNE-i 

As an example, a VNE-lp may limit the use of a VNE product to 100 instances. If the Service 
Provider wants to deploy another, say, 50 instances beyond the 100 limit, then the VNE Eicense 
would enable the creation of VNE-lp that would apply to the usage of the additional 50 VNE-i’s. 

The VNE-lp resides in the VNE Eicense Management System as a configuration file (e.g. .txt 
format). The implementation of the VNE-lp is enforced by the VNE vendor's VNE Eicense 
Manager. 

The VNE-lp is generated and supplied by the VNE vendor for review by the Service Provider 
before deployment in the VNE Eicense Management System. 


VNF 

<---t> 

VNF-li 







VNF-lp (1) 


VNF-lp (2) 


VNF-lp (3) 


Eigure 7: VNE instances and VNE policies 
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4.5 VNF License Key 

The terms VNF License and VNF License Key tend to be used interchangeably in the industry, 
and quite often mean different things to different stakeholders. Agreeing on a definition of the 
VNF License Key will reduce confusion and promote progress in achieving scalability for VNF 
deployments. The VNF License should not be confused with the VNF License Key. The former 
is a contractual construct and the latter is an operational identifier. 

The authors propose the following definition: A VNF License Key or 'VNF-lk' is a unique 
identifier for each association at a given time of VNF-i and VNF-lp. There can be an unlimited 
number of VNF-i's associated with a given VNF-lp and conversely, there can be an unlimited 
number of VNF-lp's associated with a given VNF-i. In other words, there can be an unlimited 
number of VNF-lk's which uniquely identify each such association of VNF-i and VNF-lp. 

The VNF-lk has two distinct roles: 

1. Enabling the operational lifecycle of the VNF-i 

2. Enabling the tracking of usage of the VNE-i 

4.5.1 Tracking of Usage 

The VNE-lk can be recorded in a VNE Eedger and is visible to all stakeholders that have 
appropriate access permissions. Stakeholders other than the VNE vendor (e.g. the service 
provider) need to be able to monitor the usage of VNE-i's and their associated VNE-lp's. The 
VNE-lk is the unique identifier for each association of VNE-i and VNE-lp. Therefore, it is 
important that the VNE-lk can be used in a look-up in the VNE Eedger to find a VNE-i and its 
associated VNE-lp. 

4.5.2 Operational Lifecycle 

The VNE-i can only become operational if the terms and conditions described in the VNE-i's 
associated VNE-lp are fulfilled. Therefore, the VNE-lm (vendor specific) that controls the VNE-i 
is the only element in the ecosystem that is allowed by the vendor to communicate with the 
VNE-i for the purposes of licensing the VNE-i. It does this using the VNE-lk in a proprietary 
closed communication between the VNE-lm and the VEN-i, for example, using a public key or 
dual key approach. In other words, the VNE-lk will be visible for a range of stakeholders for 
usage tracking purposes, but at the same time, cannot be used by stakeholders other than the 
VNE vendor to activate a VNE-i. 
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Figure 8: VNF license keys 


4.6 VNF License Manager 

The VNF License Manager or 'VNF-lm' is the specific vendor implementation solution for 
managing that vendor's VNF licenses associated with the VNFs provided by the VNF Vendor in 
a given Service Provider’s domain. 

Every VNF Vendor will want to have some interface with its VNF-i's to monitor the utilization 
of VNFs. In order to achieve this, there is a need for a solution which can be deployed in the 
Service Provider domain by the VNF Vendors without impacting the functioning and security of 
the VNF-i's. Also, every VNF Vendor needs to prevent exposure of its VNF-lm implementation 
so as to prevent misuse of its VNFs and exposure of its intellectual property. This is achieved by 
having vendor-specific VNF-lm. 

While the VNF-lm implementation and its interface with the VNF-i are specific to a given 
vendor (i.e. proprietary), the VNF-lm and VNF software lifecycles should be manageable 
independently. In addition, the data exchange between the VNF Vendor and VNF-lm should be 
visible to the service provider to ensure that only relevant information related to a VNF-i is 
exchanged between the VNF Vendor and VNF-lm. 

License management of a VNF-i does not have to be implemented using the vendor-specific 
VFN-lm. In those scenarios where there is established trust between the Service Provider and the 
VNF Vendor, the vendor-specific VNF-lm implementation can be bypassed. This is equivalent to 
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not having any operational licensing enforcement but simply reporting to the VNF Vendor. This 
model usually implies audits. 

Even though a VNF-lm solution is very straight forward, there are however many complexities 
that need to analyzed carefully, especially because the VNF-lm itself will be considered as 
overhead by Service Providers while running in the Service Provider domain. 

Some of the complexities and scenarios that a VNF-lm implementation must consider are 
mentioned below: 

1. Possibilities of having multiple VNF-lm's from a given VNF Vendor. 

2. Management, deployment and execution of the VNF-lm must ensure that the VNF-lm 
and VNF-i lifecycles are decoupled from one another. 

3. Vendor-specific (i.e. proprietary) solution for the interface between VNF-i and VNF-lm 

4. Possibility of having a third party VNF-lm supporting VNFs from multiple vendors 
single license manager for multiple VNF Vendors. 

5. Transparency of information exchanged between VNF-lm and VNF Vendor. 

6. Interface of VNF-lm and VNF-le. 


VNF Vendor 


VNF-lm 



Vendor spedfic protocol 



Figure 9: VNF Vendor and its VNF license manager 
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4.7 VNF License Management System 

VNF License Management System or 'VNF-lms' is the framework for managing the inter¬ 
relationship of the various VNF-i's, VNF-lp's, and VNF-lk's in a given serviee provider domain, 
and assuring adherence to the VNF-lp's agreed to with the VNF Vendor. 

It is important to note that the VNF Vendor will provide the VNFs to run in the service provider 
domain through MANO. The VNF Vendor needs to ensure that the VNF is not used outside the 
constraints of the agreed VNF-lp(s). This requires a control mechanism, which the VNF Vendor 
enables through the VNF-lm. The challenge of the service provider hosting multiple VNF-lm's 
typically are as follows: 

1. Every VNF Vendor may provide multiple VNF-lm's which run in the service provider 
domain. Managing the runtimes of these VNF-lm's will be an overhead for the service 
provider. 

2. There could be hundreds of VNF Vendors which will mean hundreds of VNF-lm's to be 
hosted and managed by the service provider. 

3. The service provider needs a standard interface into the VNF-lm's to ease their 
management even though they operate as black boxes. 

4. It is important to the service provider to have a view of what information is collected by 
the various VNF-lm's and how it is passed to the respective VNF Vendors. 

It can be expected that additional challenges for service providers hosting and managing multiple 
VNF-lm's from multiple vendors in their domain will come to light. 

These challenges are all addressed by having a single VNF-lms. 

A VNF-lms framework provides vendor-neutral implementation for the following: 

1. Centralized repository of the VNF license information for tracking and managing the 
VNF license usage throughout the service provider domain. 

2. Vendor-agnostic interface for managing and utilizing the VNF licenses. 

3. Onboarding of VNF licenses from the VNF Vendors. 

4. Lifecycle management of multiple VNF-lm from various VNF Vendors. 

5. Providing the interface between the VNF Vendor and the service provider domain. 
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Figure 10: VNF license management system 


4.8 VNF Ledger 

Today, VNF Vendors and CSPs both keep track of the license usage in their own respective 
siloed systems as it relates to billing which then have to be reconciled. There is an opportunity to 
transform those separate, sometimes manual ledgers, into an agreed and mutually trusted 
distributed ledger. We propose as a first step addressing the ledger issue with the following 
abstract construct. 

VNF Ledger (VNF-le) is the abstract repository of VNF usage information mapped to VNF-i, 
VNF-lk and VNF-lp. Information contained in the VNF Ledger can be used by various 
stakeholders to track the VNF usage. The information in the VNF-le is updated through VNF- 
1ms, which in turn collects information from various sources during the lifecycle of each VNF-i. 

Though shown as a separate entity outside the VNF-lms in figure 11, it can also be implemented 
as part of the VNF-lms solution. The purpose of showing this functional block externally to the 
VNF-lms is to explain the interaction of this functional block with other functions in the 
ecoystem. The security and integrity of the data contained within the VNF-le, and its position in 
the service provider trust model, can be ensured by specific implementations of the VNF-lms or 
otherwise. 
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Figure 11: VNF ledger and VNF license management system 

Note also that information collected by the VNF-lm needs to be communicated to the VNF 
Vendor outside the Service Provider domain. This needs to be done while both ensuring for the 
VNF Vendor that the information has not been tampered with on the one hand, and on the other 
ensuring for the Service Provider that is has visibility into that information. This can be achieved 
by applying a digital signature to information in the VNF-lm while passing that information in 
clear text format via the VNF-lms. A subset of the information will then be stored in the VNF 
Ledger by the VNF License Management System. 
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5 VNF License Management Architecture 

Using the constructs outlined above, the authors propose an architecture for VNF License 
Management that: 

a. Brings together these constructs together with suitable interfaces, some of which would 
need to be standardized 

b. Aligns with the MEF’s LSO Reference Architecture (MEF 55) 


(Ims • vnf-i) 
Standard API 
for locating VNFdm 


(lm$-lm) 
Sta^a/d API 


Service Provider VNF-lms 
(BUS) 


(Ims-lm) 
Standard API 
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Figure 12: VNF Licensing Reference Architecture for single Service Provider domain 


In figure 12, we see that the Service Provider will be hosting VNF License Managers from multiple 
VNL Vendors with each VNL-lm handling potentially very large numbers of instances of the 
vendor’s VNFs. The communications between the VNF-i’s and the VNF-lm (e.g. including 
information on how many concurrent users the VNL-i is supporting) are proprietary to the VNL 
Vendor. The NFV-MANO will also be communicating with the VNL-i’s via the standardized NLV 
Ve-vnfm interface. Typically, the VNL Vendor will prefer to have the instance of its VNL-lm in 
the network close to the VNL-i’s to reduce latency but the Service Provider will prefer not to have 
such a software entity embedded in its network resources due to both performance and security 
considerations. Lor that reason, we propose putting the VNL-lm in the Business Applications part 
of the LSO Reference Architecture together with the VNL License Management System. 

This paper also proposes that the interface between a VNF Vendor’s proprietary VNF-lm and the 
VNF License Management System be standardized for more rapid onboarding of new VNLs. 

Similarly, a standardized interface will be required between each VNL-i and the VNL-lms for the 
simple task of locating its specific VNL-lm at the beginning of the VNL-i’s lifecycle. 
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A Standardized interface will also be required between the Service Provider’s VNF License 
Management System and the VNF Vendor’s systems external to the Service Provider domain. 

Note that the interfaces between the NFV-MANO and the VNF-i’s as well as between NFV- 
MANO and the VNF License Management System (e.g. information on memory used, cores 
used, network usage and runtime) are already standardized by ETSI as Ve-vnfm and Osma-nfvo 
respectively. 

The VNF Ledger is shown in the proposed architecture as a separate logical entity which may or 
may not be included within the implementation of the VNF-lms. This is an operational 
consideration for the Service Provider. There may be use cases where use of Distributed Ledger 
Technology (DLT) as the basis for the VNF Fedger are justified, including the case of a data 
service that spans multiple operator domains as shown in figure 13. 



Figure 13: VNF Ficensing Reference Architecture for multiple Service Provider domains 


6 VNF Ecosystem 

Having defined the standardized constructs in the area of VNF license management, it is important 
to understand who the key parties in the VNF ecosystem are. For this purpose, we define the term 
VNF Ecosystem as the collective name, in the context of VNF licensing, for the participants in 
VNF commerce and the usage of VNFs in a Service Provider domain. The following are the 
authors’ definitions of the parties to the VNF Fcosystem for the purpose of VNF licensing. 
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6.1 VNF Vendors 

VNF Vendors are the companies developing and selling VNFs. VNF Vendors monetize the use 

of their VNF products by their Service Provider partners typically in one of the following ways: 

• License fee for the use of deployed VNF-i's 

• Flat rate/subscription charge irrespective of the number of deployed VNF-i's 

• Charge per VNF-i -specific transaction 

The requirements of VNF Vendors include: 

• Minimizing 

o Commercial negotiation and legal costs and time for each VNF sale 
o Pre-sales support for the integration of each VNF 
o Billing overheads for each VNF 

o Reliance on information sourced from the Service Provider partner regarding 
usage of the VNF 

• Preventing unwanted use of VNFs by those not authorized to use them or use of the 
VNFs outside the terms and conditions agreed with those that are authorized to use them. 
To achieve this, VNF Vendors require the ability to track usage of its VNFs both offline 
and online. 

• Placement of the vendor’s VNF License Manager (VNF-lm) in close proximity to the 
VNF-i’s in the infrastructure typically to minimize latency in the interactions between the 
VNF-lm and VNF-i. This may be a carry-over from the era of element managers needing 
to be close to the physical network devices for reliable control of those devices, however 
this often is not necessary in today’s implementations of network infrastructure. 


6.2 Service Providers 

Service Providers are the CSPs that use VNFs to enhance their products and services. 

The requirements of the Service Providers include: 

• Maximizing 

o Choice of VNFs available to them for deployment to support a functionality in a 
service, whether from one vendor or a range of vendors 
o Effectiveness of the VNFs in building in services in real-time (e.g. through 
monitoring) 

• Minimizing 

o Onboarding costs and time for each VNF 
o Integration and deployment costs and time for each VNF 
o Legal, payment and dispute settlement costs and time for each VNF Vendor 
o Placement of non-VNF-i software in the network infrastructure to avoid 
performance impact and security vulnerabilities, 
o Service disruption due to licensing issues. 
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• Ensuring that tracking/monitoring of VNF usage by VNF Vendors does not introduce 
security vulnerabilities into the Service Provider’s domain 

• Enabling tracking of 

o VNF usage for optimum return on investment 

o VNF-i usage in a sufficiently granular manner to use analytics to predict future 
financial and resource usage, allowing the service provider to adjust its 
operational models to minimize future expenditure on licenses and infrastructure. 


6.3 Third Parties 

There is a wide range of solution providers that can deliver one or more aspects of software 
solutions that simplify license management for the Service Providers and/or VNF Vendors. The 
concepts laid out in this White Paper create new opportunities for existing and new players in the 
ecosystem. Examples include: 

1. 3rd Party VNF License Management System Vendors 

Suppliers of the VNF Ficense Management System which is a specialized software 
solution and a key enabler for managing large numbers of VNF licenses and license 
policies for multiple vendors in the Service Provider domain. 

2. 3rd Party VNF License Manager Vendors 

Suppliers of the VNF Ficense Manager which is a tool that VNF Vendors deploy in the 
Service Provider domain to track and manage their VNF products in their customer 
Service Provider’s domain. Note that this creates an opportunity for commercial off-the 
shelf product vendors to supply the specialized software of the VNF Ficense Manager. 

3. VNF Ledger Vendors 

Suppliers of the VNF Fedger which will play an essential role in tracking and managing 
usage of VNFs in the Service Provider domain. The implementation of the VNF Fedger 
can be either a part of the VNF Ficense Management System or distinct and separate (e.g. 
Distributed Fedger Technology implementation that is not controlled by any single 
participant in the ecosystem). 


7 VNF Business and Trust Models 

VNF license management is intrinsically connected to both enabling business between Service 
Providers and their VNF Partners, as well as enabling trust between them. For that reason, it is 
helpful to highlight the related business and trust models in the VNF space. 
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7.1 VNF Business Models 

Once a standardized approaeh to VNF Lieense Management is achieved, it is easier to quickly 
implement, modify and enforee business models for using VNFs. Note that while VNF business 
models describe the overall approaeh to the business between the Service Provider and the VNF 
Vendor, the VNF License Policies determine specifie constraints and govern the actual usage of 
the VNFs in the context of the business model. 

Examples of such business models include: 

7.1.1 Flat 

In the Flat model, the Service Provider pays the VNF Vendor a fixed price for a set of features of 
the VNFs. 

7.1.2 Pay-as-you-Grow 

In this model, the priee varies based on the usage of the VNFs. Usage ean be determined based on 
various parameters of the VNFs like number of instances of VNFs or the number of coneurrent 
conneetions ete. VNF features ean grow progressively based on requirements. 

7.1.3 Subscription 

The subscription model provides the Service Provider with the right to use the VNF for a fixed 
period of time. Renewal by the Service Provider is required to continue the use after the period. 

7.1.4 Hybrid 

In the hybrid model, a combination of two or more of the above models is agreed between the 
Service Provider and the VNF Vendor. 


7.2 VNF Ecosystem Trust Model 

The VNF Ecosystem Trust Model is the eollection of rules, proeesses and applieations which 
ensures that the information related to the usage of the VNFs ean be trusted by the Serviee 
Providers, VNF Vendors and other relevant stakeholders. The Trust Model deseribes the level of 
transparency and integrity of all the data and applications for all the stakeholders. 

Understanding in detail the Trust Model is important in the VNF ecosystem beeause the VNFs 
and VNF Lieense Managers are supplied by the VNF Vendors but are operated in the Serviee 
Provider domain using Service Provider resourees. 

An unsuitable Trust Model makes it diffieult to support a wide range of implementation and 
business scenarios. This is the typical situation currently and as a result the Trust Model today is 
usually underpinned by extensive legal agreements and minimal monitoring. 
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An effective Trust Model will ensure that all the stakeholders are coordinated in an automated, 
highly scalable manner regarding all aspects of the usage of VNFs in the Service Provider 
domain. 

The Service Provider needs to trust the following artefacts and information from the VNF 
Vendor: 

• VNF will operate as specified by the VNF Vendor 

• VNF will not introduce any security threat or vulnerabilities - maliciously or accidentally 
- into the Service Provider domain 

• Vendor's VNF License Manager will operate in an 'honest' and complete fashion in the 
Service Provider domain without creating significant operating overhead for the Service 
Provider 

Conversely, the VNF Vendor needs to trust the following information from the Service Provider: 

• Usage data regarding its VNF product operations (e.g. how many VNF-i's in the system; 
number of cores being used, number of concurrent users, geographic location etc.) 

In order to maximize transparency, the Trust Model should ensure that the information 
exchanged between parties is visible to them and any modification to the information is also 
auditable and is part of the information exchanged itself. 


8 Summary 

There is a disconnect today in the CSP industry between business requirements and VNF 
technology solutions. The business people in the Service Providers are challenged in explaining to 
their engineering teams their requirements in terms of managing VNF licensing - a very important 
aspect of working with virtualized resource suppliers. Similarly, the Service Provider architects 
and engineering teams are challenged in designing their OSS/BSS environments with an 
understanding of these business requirements and how to handle them. This leads to a VNF 
licensing architecture with a Trust Model that requires extensive legal and commercial negotiation 
for each VNF and very limited business model options. 

This White Paper firstly proposes that Service Providers and VNF Vendors adopt the standardized 
terminology and architectural framework described in this document to enable more effective trust 
and business models for use of VNFs. This will have the benefit of making VNF usage much more 
scalable, opening up the market to new and innovative VNF products from a wide variety of VNF 
Vendors. The authors also propose underpinning this proposed terminology and architectural 
framework with standardization work. 

Secondly, the authors propose adopting and extending the Intent-based business language 
currently being developed in MEF in the context of SD-WAN service and policies specification to 
the area of VNF license policies. By enabling business and legal stakeholders in both Service 
Providers and VNF Vendors to directly create machine-readable master agreements and terms and 
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conditions, a dramatic acceleration of the negotiation phase relating to use of VNFs can be 
achieved. 

Finally, the authors propose that a large-scale Proof of Concept is developed to demonstrate how 
effective trust models and business models based on the framework proposed in this whitepaper 
can enable scaling for large numbers of VNFs both in a single Service Provider domain use case 
and in a multiple Service Providers domain(s) use case. 


9 About MEF 

An industry association of 200-1- member companies, MEF has introduced the MEF 3.0 
transformational global services framework for defining, delivering, and certifying assured 
services orchestrated across a global ecosystem of automated networks. MEF 3.0 services are 
designed to provide an on-demand, cloud-centric experience with user- and application-directed 
control over network resources and service capabilities. MEF 3.0 services are delivered over 
automated, virtualized, and interconnected networks powered by ESO, SDN, and NEV. MEE 
produces service specifications, ESO frameworks, open ESO APIs, software-driven reference 
implementations, and certification programs. MEE 3.0 work will enable automated delivery of 
standardized Carrier Ethernet, Optical Transport, IP, SD-WAN, Security-as-a-Service, and other 
Eayer 4-7 services across multiple provider networks. Eor more information, visit 
https://www.mef.net and follow us on Einkedin and Twitter @MEE_Eorum . 


10 Terminology 


Terni 

Definition 

Reference 

Communications Service 

Company offering, among other services, data- 


Provider 

oriented services to consumers and/or enterprises 
based on data network infrastructure. Referred to in 
this document as ‘Service Provider’ for easier 
reading. 


CSP 

Communications Service Provider 


NEV 

Network Eunction Virtualization 


Eicense 

Agreement on use of a product or service between a 
buyer and a seller. 


Eifecycle Service 

Standardized framework for intra-provider and inter 

MEE 55 [3] 

Orchestration 

provider orchestration of data-oriented services 


ESO 

Eifecycle Service Orchestration 


MANO 

Management and Network Orchestration 

www.etsi.org 

Network Eunction 

Set of ETSI standards covering enabling the use of 

www.etsi.org 

Virtualization 

software running on generic compute platforms for 
any aspect of network functionality. 


Service Provider 

Used in this document instead of CSP or 
Communications Service Provider for easier 
reading. 
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Trust Model 

Collection of entities and processes that service 
providers rely on to help preserve security, safety 
and privacy of data. 


VNE 

Virtualized Network Eunction 


VNE Instance 

Software clone of VNE deployed on a network. 

Abstract 

construct 
proposed in this 
White Paper 

VNE Eedger 

Database (DET-based or centralized) of information 

Abstract 


pertaining to licensing, management and usage of 
VNE Instances. 

construct 
proposed in this 
White Paper 

VNE Eicense Key 

Unique operational identifier for unique association 
between a VNE Instance and a VNE Eicense Policy. 

Abstract 

construct 
proposed in this 
White Paper 

VNE Eicense Manager 

Eunctionality that manages, monitors and polices 
the licensing and related usage aspects of a VNE 
Instance. Typically developed by the vendor that 
develops the VNE. 

Abstract 

construct 
proposed in this 
White Paper 

VNE Eicense Policy 

Set of rules and conditions in electronic format 

Abstract 


readable by software for use of a VNE Instance. 

construct 



proposed in this 
White Paper 

VNE lifecycle 

Steps in the life of a VNE Instance including 
deployment, management and termination. 


VNE-i 

VNE Instance 


VNE-le 

VNE Eedger 


VNE-lk 

VNE Eicense Key 


VNE-lm 

VNE Eicense Manager 


VNE-lms 

VNE Eicense Management System 


VNE-lp 

VNE Eicense Policy 
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